LeSS Huge 框架是針對 8 個以上團隊的作法. 如果沒有特別的說明, LeSS 框架的規則都是用於 LeSS Huge 框架. LeSS Huage 會包含一些 LeSS, 所以自然規則是會套用進去.

A. LeSS Huge 結構(Structure)

(1) 從客戶角度來找出, 相關性強的客戶需求會以需求領域 (Requirement Areas) 分組
(2) 每個團隊專職一個需求領域。團隊會長期固定於某個領域，但是當其它領域的價值變得更高時，團隊也可能改變其工作的需求領域
(3) 每個需求領域有一個領域產品負責人 (Area Product Owner)
(4) 每個需求領域有“4-8”個團隊。避免超出這個範圍
(5) LeSS Huge的導入 (包括其結構的變化) 是以逐漸演進的方式發生的
(6) 每天都要記得：LeSS Huge的導入會需要花幾年或幾個月、需要很多的耐心、還有一些幽默感
來源: https://less.works/less/rules

需求領域 (Requirement Areas) 是 LeSS Huge 的一個新的觀念. 對於超級大型的產品或是系統, 要大多團隊都能夠處理大部分的條目是蠻難的. 因此, 一個作法是先將這個超級大的範圍, 拆解成幾個略為獨立的子範圍, 其中的團隊先針對某個子範圍開始處理, 之後再熟悉其他領域. 這樣每個子領域就可以利用 LeSS 來處理. 這樣的子領域就是需求領域.

B. LeSS Huge 產品(Product)

(1) 有一個整體的產品負責人, 來負責產品層面的優先級排序, 和決定哪些團隊工作在哪個領域。這個整體的產品負責人和所有的領域產品負責人會緊密地一起協作
(2) 領域產品負責人對他們的團隊來說就是產品負責人
(3) 有一份產品待辦列表；裡面的每個條目只會屬於某一個需求領域
(4) 每個需求領域有一份領域產品待辦列表。這個列表概念上來說, 是整個產品待辦列表更細粒度的視角
來源: https://less.works/less/rules

整體的產品負責人和所有的領域產品負責人會頻繁合作, 這件事情也是和其他框架不同之處. LeSS 系統化地把問題切小, 對於切小的部分都用 LeSS 框架處理. 並且為了優先順序能一致, 讓整體的產品負責人決定最終的優先順序. 然後利用領域產品負責人來分擔整體的產品負責人的工作, 這樣在優先級和工作量上就可以取得平衡.

C. LeSS Huge Sprint

(1) 有一個產品層面的Sprint，而不是針對需求領域有不同的Sprint。這樣每個Sprint會帶來一個整合過的整體產品
(2) 產品負責人和領域產品負責人會頻繁同步。在Sprint計劃前, 他們確保團隊都工作在最有價值的條目上。在Sprint Review後，他們在產品層面做出調整。
來源: https://less.works/less/rules

LeSS Huge 中雖然人數更多, 但是還要有一個產品負責人, 負責整體的優先順序. 並且 Sprint Review 看到的, 也是所有團隊整合在一起的增量. 這些都是告訴你, LeSS Huge 還是關注整體的.